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introduction 


1.1 Purpose and Scope 

3Ei lypcof ««!•«.« dewces or oih« types of libri-... « 
for the programming data this protocol is not required. 

Tins standard defines a data format for transferring the fuse or cell states between the development systan and the 
U d^notdefme the device architecture such as types oflogic arrays or the output macro cell. Also 
the^tandard does not define the programming algorithms or the device and technology specific informauon or 
necking the fuses or cells. 

Field-programmable logic devices may require more testing than programmable memories, so Ae smtod defines a 
simple ftmcfional testing format This test vector format is not a general purpose parametric test languag . 


<STX>File for PLD 12S8 Created on 8-Feb-85 3:05PM 
6809 memory decode 123-0017-001 
Joe Engineer Advanced Logic Corp * 

QP20* QF448* QV8* 

F0* XO* 

loooo liiiioiuiiii min ii liiiin* 

L0028 101111111111111111111H Hi 11* 

L0056 liioiiimii min mi ini n* 

L0112 010101110111101111111111 nil* 

L0224 oioioiinoi lioimmim m* 

L0336 01010111011101 111 1111 nil 111* 

V0001 OOOOOOXXXNXXXHHHLXXN* 

V0002 010000XXXNXXXHHHLXXN* 

V0003 100000XXXNXXXHHHLXXN* 

V0004 110000XXXNXXXHHHLXXN* 

V0005 lllOOOXXXNXXXHLHHXXN* 

V0006 111010XXXNXXXHHHHXXN* 

V0007 111 100XXXNXXXHHLHXXN* 

V0008 limOXXXNXXXLHHHXXN* 

C124E*<ETX>8A76 


Figure 1. Example of a Programmable Logic Device Data File 
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1.2 Summary of Programming and Testing Fields 

The programming and testing information is contained in various Gelds. The following list gives the Geld identifier 
and a d nnipti™ To comply with the standard the device programmer, tester, and development system must 
provide and recognize certain fields. 

Identifier Description 
(n.a.) Design Specification 

N Note 

QF Number of Fuses in Device *** 

QP Number of Device Package Pins * M 

QV Maximum Number of Test Vectors 

F Default Fuse State * E Electrical Data * 

L Fuse List * U User Data 

C Fuse Checksum J Device Identification 

X Default Test Condition ** 

V Test Vectors ** 

P Pin Sequence” 

D Device (Obsolete) 

G Security Fuse 

R,S,T Signature Analysis 
A Access Time 

* Programmer must recognize 

** Tester must recognize 

•** Development System must provide 

1.3 Changes to October 1983 Standard 

The 1983 standard defined the D, F, L, C, V, and P field. Several other fields are now being used, and this new 
standard formally defines these fields. The new standard is a superset of the 1983 standard. 

The sequence and allowed combinations of the various fields have been clarified. One field, the D field, was not 
clearly defined and this led to conflicting uses. The D field is made obsolete in this standard. 

Several changes have been added to the test vectors to defined unspecified vectors and don't care conditions. The 
test vectors now allow for manufacture independent register preloading. 

1.4 Changes clarifying preload test vectors 

The B preload test vector, intended to allow preloading of buried registers, has been clarified. The previous 
definition was ambiguous. In addition, register numbering guidelines have been added, and a "read-and-retain" test 
condition has been added to allow selective preloading of registers, without disturbing other registers. 

In Standard 3-A, the QP field was defined as containing the number of pins in the test vectors. The new standard 
defines the QP field as containing the number of pins on the device package. Conditions under which the QP field 
is mandatory are listed in 5.4 
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1.5 Addition of a register observation vector 

A T vector has been added to allow the observation of all registers in a device. This allows equal access to output, 
input, and internal registers. Its format parallels that of the B preload vector. 

1.6 Additions to JESD3-B which implement JESD3-C 

Electrical Fuse Data (E): The E field has been added to allow for the handling of special feature fuses that do not 
affect the fucntion of the device. An example of this type effuse is the power miser fuses available m some 
types of PLD devices. With this addition, the integrity of the L field will remain intact such that one common 
JEDEC file can be utilized to program any device with the same logical functionality. 

User Data (U)' The U field has been added to allow for the handling of special feature fuses that do not affect the 
logic function of the device. An example of this type of fuse is the User Data Signature (information only) 
av ailable in some types of PLD devices. With this addition, the integrity of the L field will remain intact such that 
one common JEDEC file can be utilized to program any device with the same logical functionality. 

Device Fw;fi«.tinn (J): The purpose of the J field is to provide a means of verifying that a particular JEDEC file 
is appropriate for the device which has been selected for programming. Each PLD architecture is assigned a 
unique code, and each pinout variation of an architecture is assigned a unique code. Uniqueness is defmed more 
thoroughly below. The intent is for the device programmer to check the device and JEDEC file before 
programming and then issue an error message if the device code in the JEDEC file does not match the device type 
that has been selected for programming. This field does not provide for verification of the actual device in the 

socket 

SPECIAL NOTATIONS AND DEFINITIONS 
2.1 Notation Conventions 

In addition to descriptions and examples this document uses the Backus-Naur Form (BNF) to define the syntax of 
the data transfer format BNF is a shorthand notation that follows these rules: 

o denotes "is defmed as". 

o Characters enclosed by single quotes are literals (required), 
o Angle brackets enclose identifiers, 
o Square brackets enclose optional items. 

o Braces (curly brackets) enclose a repeated item. The item may appear zero or more ti m e s , 
o Vertical bars indicate a choice between items. 

o Repeat counts are given by a :n suffix. For example, a six digit number would be defmed as "<number> 
<digit>:6." 


For example, in words, the definition of a person's name reads: 

The full name consists of an optional title followed by a first name, a middle name, and a last name. The 
person may not have a middle name or may have several middle names. The titles consist of: Mr., Mrs., 
Ms., Miss, and Dr. 
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BNF Syntax: 

<full namo [<title>] <f. narae> {<m. name>) <1. name> 

<title> ::= ’Mr.’ | ’Mrs.’ | 'Ms.' I ’Miss' | Dr.* 

Examples 

Miss Mary Ann Smith 
Mr. John Jacob Joseph Jones 
Tom Anderson 

12 BNF Rules and Definitions 

The following standard definitions are used throughout the rest of this document: 

<digit>:-t)Tr|T|3T4‘ 

| *5* 116* | T | IF | *9* 

<hex-digit> <digit> 

\'A'\ r B\'C\'U\ f E\T 

<binaiy-digit> ::= V | T 

<numbei> ::= <digit> (<digit>) 

<del> <space> | <carriage retum> 

<deiimitei> <del> {<del>} 

<printable character> <ASCII 20 hex... 7E hex> 

<control character :: = <ASC1100 hex ... IF hex> 

| <ASCH 7F hex> 

<ASCn 02 hex> 

::= <ASCH 03 hex?* 

<ASCn OD hex> 

- <ASCn 0A h ck> 

:-<ASCn20 hex> | ” 

<valid character ::= <printable character 

| <cairiage retum> | <line feed> 

<field character ::= <ASCn 20 hex... 29 hex> 

| <ASCII 2B hex ... 7E hex> 

| <camage retum> | <line feed> 


<STX> 

<ETX> 

<camagc retum> 
<line feed> 
<space> 
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2.3 PLD Register numbering 

Tlie B and T wcton require that PLD —Am. P™* • ■“ 
PLD programmer vendors. This numbering sequence will be used m the B and T ec 

The registers are numbered from 1 to N, where N is the maximum numberof registers in the device. The PLD 
manufacturer is responsible for assigning and documenting the register numbers. 

sSS—rHS-xS 

register, then this register is classified as an output register for register numbering purposes. 

Registers must be sequenced in the following order: 

1. Output and I/O registers 

2. Internal registers 

3. Input Registers 

Within a group, all registers should be numbered in ascending sequence, in the order of the 
programmable elemental can be associated with each register. For example if the lowest 
usedbvintenial register A is 31 and the lowest-numbered element used by internal register B is 61 than A is 
numbered first in the register sequence. However, even if the lowest-numbered^element usedby oupu regi 
is 91, C is still numbered ahead of A and B, since output registers are numbered before internal registers. 

TRANSMISSION protocol 
3.1 Protocol Syntax 

This simple STX-ETX protocol is based on traditional PROM formats that allow a device programmer to share a 
S^l ZpuSport X terminal. The transmission consists of a start-of-text (STX) character, vano^ fields an 
end-of-text (ETX) character, and a transmission checksum. The character set consists of the pnntable ASCII 
characters and four control characters (SIX, ETX, CR, LF). Other control characters should not be used because 
they can produce undesirable side-effects in the receiving equipment. 

Syntax of the Transmission Protocol: 

<format> <STX> {<field>} <ETX> <xmit checksum^ 
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3.2 Computing the Transmission Checksum 


TW ch«k»» bt. um* — tu. l — 

including the STX and ETX (sec figure 2). The parity bit is excluded in the calculation. 


Syntax of the Transmission Checksum: 


<xmit checksum> <hex-digit>:4 


random text <retumxlinefeed> -0000 

<STX>TEST*<retumxline feed> 02+54+45+53+54+2A+OD+0A = 0183 

OF 0384 •<retumxline feed> 51+46+30+33+38+34+2A+OD+OA = 01A7 

FO* <retumxline feed> 46+30+2A+2O+20+0D+OA = 00F7 

L10 101 *<retumxline feed> 4C+31+30+20+31+30+3 1 + 2 A+OD+OA-OIAO 
<ETXX)5C4 <retum> random text 03 * 0003 


05C4 


Figure 2. Computing the Transmission Checksum. 

3.3 Disabling the Transmission Checksum 

Some computer operating systems do not allow the user to control what characters are sent, especially at 1he.end of 
a line. The receiving equipment should always accept a dummy value of "0000" as a valid checksum. This dummy 
checksum is a method of disabling the transmission checksum. 


4 DATA FIELDS 


4.1 General Field Syntax 

In general, each field in the format starts with an identifier, followed by the information, and terminated with an 
asterisk. For example, *C1234** specifies that the checksum of the fuse data is 1234. The design spectiication 
header docs not have an identifier and must be the first field in the transmission, immediately following the STX. 

Syntax of Fields: 

<field> ::= [<delimited] <field identified 
{<field characted) 

<field identified ::= 'A' | T | V | E | T | ’O'17 

IVIWIT-I'QTIW 

I’S'iT | tri v| , X’ 

<rescrved identified ’B 1 1 If | T | *K' 

|M|0|W|Y|T 
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4.2 Field Identifiers 


Each field begins with a single character identifier that identifies Ute field type. Multiple 
be used tocreate subfields (i.e., 'Al*. *AJ\ or "AB3"). The field is terminated with an asterisk 
asterisks cannot be embedded within the field. While not required, carnage retorts and line feeds should be used 
to improve the readability of the format. Reserved identifiers currently have no functional are reserved for futo 
use. ^Receiving equipment should ignore fields starting with reserved identifiers. The meanings of the field 
identifiers are given in table 1. 


A - Access Time 
B - • 

C - Checksum 
D - Device type 
E - Electrical Fuse Data 
F - Default fuse state 
G • Security fuse 

I-* 

J - Device Identification 
K-• 

L - Fuse list 
M- • 


N-Note 

O-* 

P - Pin sequence 
Q- Value 

R - Resulting vector 
S - Starting vector 
T - Test cycles 
U - User Data 
V - Test vector 
W-* 

X - Default test condition 
Y- * 

Z-» 


Table 1. Field Identifiers (* indicates reserved for future use) 


COMMENT AND DEFINITION FIELDS 


5.1 Design Specification 

The design specification is the first field in the format, must be included, and does not have an identifier signaling 
its start. An asterisk terminates the field. The contents of the design specification are not defined but should 
consist of 


1. User's name and company 

2. Date, part number, and revision 

3. Manufacturer's device number 

4. Other information 


Syntax of the Design Specification: 

<design specifications ::= {<£Ield characters} *** 
Example: 

File for PLD12S8 
Created on 8-Feb-85 3:05PM 
6809 memory decode 123-0017-001 
Joe Engineer Advanced Logic Corp * 



JEDEC Standard No. 3-C 
Page 8 


A blank field consisting of the terminating asterisk is valid design specification field. 
Example: 


5-2 NOt ^ ote geld is used to place notes and comments in the data file. The note field(s) may appear anywhere in the 
file and the receiving equipment may ignore this field. 


Syntax of the Note Field: 

<note> W <field characters 


Example: 

N Following vectors were 


modified for the ACME 123 tester* 


5.3 Device Definition (D) Obsolete 

This field is now obsolete; it has been eliminated to ensure the format is device and technology independent 


5.4 Values (QF, QP, QV) 

He Q field expresses values or limits that must be provided to the receiving equipment Three subfields are 
defined: the F subfield for the number of fuses, the P subfield for number of puis or test conditions m the test 
vector, and the V subfield for the maximum number of test vectors. 

These values enable the receiving device to efficiently allocate memory and perform certain calculations. The QF 
field tells the receiving equipment how much memory to reserve for fuse data, the number of fuses to set to the 
default condition, and the number of fuses to include in the fuse checksum. 


The QP field tells the receiving equipment the number of physical package pins on the device. This field is 

mandatory if the following three conditions exist: . , 

a) non connected pins exist on the device (such as a 24-pin device packaged m a 28-pm SCC), an 

b) the file contains test vectors, and . . 4 , . .._ 

c) the programming equipment does not automatically handle the translation required to accommodate the n 

connected package pins. 


The value fields must occur before any device programming or testing fields in the data file. Files vriffi only testing 
fields do not require the QF field and files with only programming fields do not require the QP and QV fields. I e 
QP field must specify all device pins for files that contain B preload vectors. 


Syntax for Value Fields: 

<fose limits ::= QF <number> '*’ 
<number of pins> ::= QF <number> 
cvector limit> ::= QV <numbei> '*' 


Example: 

QF1024* Indicates device has 1024 fuses 
QP24* Indicates 24 pins on device package 
QV250* Indicates a maximum of 250 test vectors 
Table 2. Test Condition 
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DEVICE PROGRAMMING FIELDS 


6.1 Syntax and Overview 

Each fuse or cell of a device is assigned a decimal number and has two jx,ssible states: a zero, specifying a low 
resistance link (a logical connection between two points); or a one, specifying a high resistance link (no logical 
ejection between two points). The fuse numbers start at zero and are consecutive to die maximum fuse number. 
For example a device with 2048 fuses would have fuse numbers between 0 and 2047. Fuse information describing 
!he STf^hlTin the device is given by three fields: die default state (F field), the fuse list (L field), and the 

fuse checksum (C field). 


All user programmable fuses or cells may be specified with a L field. There are no separate fields for control terms 
or architecture fuses. 

Syntax of the Fuse Information fields: 

<fuse inf ormation ::= [<default state>] <fuse list> 

{<fuse list>) [<fiise checksum^] 


<default state> ::= T <binary-digit> 


<fuse list> ::= *L* <number> <delimiter> 

{<binary-digit> [<delimitex>]} '** 

<fuse checksum> C* <hex-digit>:4 

Example: 


Yd* 

L0000 01001110 00001000 11110000 11111111 01010001* 
C021A* 


6.2 Fuse Default State (F) 

The F field defines the state of fuses that are not explicitly defined in the L field. If no F field is specified, all fuse 
states must be defined by L fields. If the default state is used, it must be specified after the QF field and before the 
first L field. 

Example: 

F0* Set default to 0 
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6.3 Fuse List (L) 


The L field starts with a decimal fuse number and is followed by a 
may include leading zeros (i.e. "L12" and "L0012" are the same), 
the fuse number from the fuse states. The stream of fuse states 
allowable fuse number). 


stream of fuse states (0 and 1), The fuse number 
A space and/or a carriage return must separate 
can be as long as desired (up to the maximum 


If the state for a fuse is specified more than once, the last state replaces all previous ones specified for that fuse. 
This allows a file to be modified or ’‘patched" by appending new fuse states to the file. 


Example: 

LQOOO 

111110111111111111111111111 

loiiiiuiniiiiiiiiininii 

111011111111111111111111111 

000000000000000000000000000 * 


Example: 

LQOoo 

11111011111111111111111111110111111111 

1111111111111111 

11101111111 

1111111111111111 

000000000000000000000000000 * 


Example: 

loo liiiioiiiiiiiiiiiiini mu* 

L28 loiiiniiiiiniiniiiniiii* 
L56 lllOUllllllllinilllllUll* 
L84 000000000000000000000000000* 


6.4 Fuse Checksum (C) 

The fuse information checksum field is used to detect transmitting and receiving errors. The checksum is for the 
entire device (fuse number 0 to maximum fuse number set by the QF field), not just the fuse states sent If multiple 
C fields are received only the last is significant 

The field contains the 16-bit sum (i.e., modulo 65,535) of the 8-bit words containing the fuse states for the entire 
device. The 8-bit words are formed as shown in figure 2. Unused bits in the final 8-bit word are set to zero before 
the checksum is calculated. 

word 00 |msb| Mill \^\ 

Fuse No. 7 6 5 4 3 2 1 0 

word 01 |msb| Mill l lsb l 
FuseNo. 15 14 13 12 11 10 9 8 


word 62 |msb| Mill H s b| 
FuseNo. - - - - 499 498 497 496 
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Figure 2. 8-Bit Words formed from fuse states for Checksum 

QF500* 

FO* 

loooo oioomoooooiooo linoooo liminoioioooi* 

C021A* 


Fuse 



Number MSB LSB 


0000 

01110010 

72 

0008 

00010000 

10 

0016 

0000 1 1 1 1 

OF 

0024 

11111111 

FF 

0032 

10001010 

8A 

0040 

00000000 

00 

0048 

00000000 

00 

0488 

00000000 

00 

0496 

----0000 

00 


Fuse Checksum 021A 
Figure 3. Computing the fuse checksum. 


6.5 Electical Fuse Data (£) 

The E field allows special feature fuses that do not affect the logic function of the device to be added without impact 
to existing JEDEC files for that device. An example of this type of fuse is the power miser fuse available in 
some types of PLD devices. With this addition, the integrity of the L field will remain intact such that one common 
JEDEC file can be utilized to program any device with the same logical functionality. 

There are two types of E fields depending on how the data is entered. The E field is for binary data, and the EH 
field is for Hex data. 

Syntax of the E field: 

<Electrical DATA FUSE LIST>: :'E , <binary digits'*' 

•EH^iex digit>‘*' 


Examples: 

NO ELECTRICAL FUSE DATA ELECTRICAL FUSE DATA PRESENT 


QF24* 

LOOOO 

101011000000000000000000 * 


COOAC* 


QF24* 

LOOOO 


101011000000000000000000 * 

COOAC* 

E10100111* 


The E and H fields are read left to right from MSB to LSB. 
Example: 

Binary E11001010* 
or 
Hex 


EHCA* 
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6.6 User Data (U) 

The U field allows user data fuses that do not affect the logical or electrical functionality of the device to be added 
without impact to existing JEDEC files for that device. An example of this type of fuse is the User Data 
Signature (information only) available in some types of PLD devices. With this addition, the integrity of the L field 
will remain intact such that one common JEDEC file can be utilized to program any device with the same logical 
functionality. 

There are three types of U fields depending on how the data is entered. The U field is for binary data, the UA field 
is for ASCII field characters, and the UH field is for Hex data. 

Syntax of the U field: 

<User DATA FUSE LIST>::'U’<binary digits'*' 

TJA'<field character?*' 

TIH'<hex digit?-'*' 

The U, UH, and UA fields read left to right from MSB to LSB. If the field defined is larger than the available 
space in the device, the most significant bits should be truncated by the programmer until the appropriate size is 
reached. If the field is smaller than the available space in the device, the data will be fit into the device by the 
programmer beginning with the least significant bit. The unused bits will be filled with zeros by the programmer. 
There will be some binary combinations that cannot be represented as a field character in the UA field. The field 
characters) in the UA field are assumed to be 7 bit quantities. U field data is not to be included in the C field fuse 
checksum. 

Example: File with 28 user fuses 

Binary U1010100100010110110001010100* 
or 

Hex UHA916C54* 
or 

ASCII UATEXT* 

Examples: 

NO USER DATA FUSES USER DATA FUSES PRESENT 

QF24* QF24* 

L0000 LOOOO 

101011000000000000000000 * 101011000000000000000000 * 

C0035* C0035" 

UATEST 
MSB LSB 
MSBYTE LSBYTE 
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6.7 DEVICE IDENTIFICATION (J) 


The J field provides a device identification code that uniquely specifies the logical architecture of the devicei for 


front of any F, L, or H fields. The J field is optional. 


Syntax for JEDEC device identification field: 

<device code>::=J<numbei><space><nuinber>* 


The numbers in the J field are decimal integers greater than or equal to zero (0) as allowed below. The actual 
number for any given device is assigned by JEDEC as defined below. 


The special pinout code zero (0) will be used to indicate that for a given JEDEC file, no ^ 

enforced In this case, only the architecture code will be used to determine the appropriateness of the JEDEC file 

for the device selected. 


Maximum protection is provided to the user by the combination of the architecture and pinout codes. 

In no way is this code to be construed as an endorsement by JEDEC of any architecture or pinout Any device can 
be given a code, and no architecture or pinout standardization is implied 

The number used in the J field is assigned by JEDEC. Contact the JEDEC office for the request of a Device Code 
form and details on assignment procedures. 


A code assignment application fee will be charged by the JEDEC office. An invoice will be sent to the Sponsor, 
according toffee schedule approved by the JEDEC Solid State Products Council. The fee schedule may recognize 
a group assignment for a family of devices that are receiving codes at the same time. 


7 DEVICE TESTING FIELDS 
7.1 Syntax and Overview 

Functional test information is specified by test vectors contaming test conditions for each device pin. 

Syntax of Functional Test Information: 

<firaction tesu> [<default test condition] 

[<pin lisO] <test vectoi> 

{<test vector>} 

<default test condition> X <binaiy digits ’** 

<pin iist> ::= V <pin number>:N '•* 

<pin number> ::= <delimitei> <numbei> 

N ::= number of pins on device 

<test vector> ::= V <numbei> <delimiter> 

<test condition>:N 


T | TT | X | ’Z’ 


<test condition> ::= <digit> | *B* | | T) 1 1 T*1 IT | 
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<reserved condition> A* | E* | *G' | T | 'T1 TvT | 

| •Q' | 'S' | v | w | v 


0 - Drive input low 
1 - Drive input high 
2-9 - Drive input to super voltage #2-9 
B - Buried Register preload 
C - Drive input low, high, low 
D - Drive input low, fast transition 
F - Float input or output 
H - Test output high 
K - Drive input high, low, high 
L - Test output low 

N - Power pins, outputs not tested, and non- connected device pins 

P - Preload registers 

R - Read and retain register state 

T - Observe registers 

U - Drive input high, fast transition 

X - Output not tested, input default level 

Z - Test input or output for high impedance 

Table 2. Test Conditions 


7,2 Default Test Condition (X) 

The X field defines the input logic level for test vectors not explicitly defined and for the "don't care" test condition. 
The X field will set test vectors 1 through the maximum (set by QV) to the default input test condition. If the X 
field is used, it must be specified after the QV and QP fields and before the first test vector. 

Example 

XI * Set default test condition to 1 

In the following example vectors 2 and 5 would default to the don't care value of 0 and no outputs would be tested 
for vectors 2 and 5. 

Example 

QV5* 

QP20* 

XO* 

V0001 101010000NOZLLHHZ1 IN* 

V0003 111XXXXXXN0ZHHLLZ11N* 

V0004 011XXXXXXN0ZLHLHZ1 IN* 
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7.3 Test Vector* 

Each test vector contains N test conditions where N is the number of pins on the device. Table 2 lists the conditions 
that can be specified for device pins. 


The V field starts with a 
pin, and terminated by an 


decimal vector number, followed by a space, then by a senes 

asterisk. The vector number may include leading zeros. 


of test conditions for each 


Example: 


V0001 OOOOOOXXXNXXXHHHLXXN* 
V0002 OlOOOOXXXNXXXHHHLXXN* 
V0003 1OOOOO XXXNXXXHHHLXXN’ 
V0004 110000XXXNXXXHHHLXXN’ 


The vectors are applied in numerical order to the device being tested. The highest numbered vector to be apphed is 
defu^ b^OV field. If a vector is not specified during a data transfer the default value or a vector from a 
Previous gamier will be used. If the same numbered vector is specified more than once, the data in ^J 231 
replaces any data contained in previous vectors with that number. This allows the set of test vectors to be modified 
or "patched" without transferring the entire set. 


7.4 Pin Sequence 


The conditions contained in test vectors are applied to the dev.ce pms m numencalortofromleft to nghtunk* 
specified otherwise with the P field. (The leftmost condition is applied to pin 1, and the ni£tm«4“ 
applied to pin 20 of » 20 pin device, for example. The timing sequence is not defined; a test common maybe 
ied to pin 5 before or after pin 4.) The P field indicates an alternative correspondence betweai thet«n 
conditions Li the pin numbers. Each package pin, including nonconnects, must be represented by a number m the 

P field. 


Example: 

P 1 2 34 5 6 14 15 16 1778 9 10 11 12 13 18 19 20* 


V0001 111000HUIHNNNNNNNNNN* 

V0002 100000HHHD4NNNNNNNNN* 

Vector 1 will apply 111000 to pins 1 through 6 and HLHH to pins 14 through 17. Pins 7 through 13 and 18 through 
20 arc not tested (N). 


7.5 Test Conditions 


The test condition logic levels are defined by the device technology (e.g. TTL, CMOS ECL). The 0 and 1 
conditions apply a steady state logic level to the device pm. The device tester should allow the applied rnpu 
conditions to be overridden by bidirectional (input/output) device pms. The X or dont care test condition applies 
the default level defined by the X field. The F test condttion applies a high impedance to the device pm. 


The sequence that the input conditions are applied to the device is not defined, so multiple vectors should be used 
when the sequence is important The following example ensures that pin 4 transitions to a logic level 1 before pm 

3. 


V01 XXOOXXXXXNXXXXXXXXXN* 
V02 XX01XXXXXNXXXXXXXXXN* 
V03 XXI1XXXXXNXXXXXXXXXN* 
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The test conditions 2 through 9 apply a non standard or super voltage to the device. This may be used to access 
special test modes. The levels are defined for each device and test vectors utilizing super voltages could damage 
"second source" devices. 

The C test condition applies a logic level 0 until all other inputs are stable (and device timing specifications are 
met) then switches to a logic level 1 and returns to a logic level 0 before the outputs are tested. The K test 
condition goes from 1 to 0 to 1 in a similar manner. For devices more than one clock input, multiple test vectors 
should be used to ensure the proper clocking sequence. 

The U test condition applies a logic level 0 until all other inputs are stable and internal set-up times met, then 
switches to a logic level l and remains at that level. This test condition should be used for any clock input that 
must make a single 0 to 1 transition. It is differentiated from the T test condition in that the device tester does not 
allow the input condition to be overridden by bidirectional device pins, thus allowing the U test condition to make a 
much faster transition. The D test condition is analogous to the U test condition except it applies a logic level 1 
until all other inputs are stable and internal set-up times met, then switches to a logic level 0 and remains at that 
level. 

The N test condition is used for power pins, output pins not tested, and non connected device pins. 

After all inputs have stabilized, including clock, the output test are performed. The L test for a logic level 0 and the 
H test for a logic level 1. 

The Z test condition test that an output is in a high impedance condition. 

7.6 Register Preload 

Register Preload means forcing or "jam loading" a register to a known state. Three types of register preloading are 
defined: "in-circuit", "output register", and "buried register". 

"In-circuit" preload is accomplished with dedicated input pins and/or internal control logic and uses normal 
in-circuit logic levels. The standard input and clock test conditions may be used to preload the registers in these 
devices. The "output register" and "buried register" preload operations use non standard levels or "super voltages" 
to access special modes to preload the registers. 

Because testing algorithms are unique for each device, the following generic methods may allow one set of test 
vectors to work with "second source" devices. The device programmer/tester will apply the specific superalgorithm 
for each device type. 
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7.6.1 P Preload Vector 

A P preload vector is used to preload PLDs with output registers connected to device pins. The P preload vector is 
used to set the pins to a desired state. 

after the preload operation. 

Example 1. Preload a 16R4 with the P preload symbol. 


11111111112 <-position in the 

12345678901234567890 vector 
V0001 PXXXXXXXXNXXX1101XXN* 

V0002 OXXXXXXXXNOXXHHLHXXN* 


<- P preload 
vector 
<-check 
loaded value 


because of the inverting buffer in front of the 16R4 register. 

The PLD programmer must set up the appropriate input and clock conditions for aF>^ 

properly For^ample, the outputs must be disabled for a 16R4 device by specifying al for the active LOW «able 

mTintiie preload vector. This is part of the preload algorithm that must be supplied by t ^ e ^£ 

The designs' must specify Xs (dont cares) for any unused input pins m the preload vector If a^mboi other than X 
is specifledTthe value required by the device algorithm in the PLD programmer will take precedence. 

For devices with different clock pins controlling separate banks of registers, a P symbol must be applied to the 
appropriate clock pin to preload the corresponding register bank. 

The P preload vector will use the pin sequence information specified by the QP and P fields. The position of the 
preload value in a P preload vector and the pin sequence will determine which register to preload. 


Example 2: 


Preloading a 16R8 and using a second non-clocked vector to test the values preloaded 


V0001 PXXXXXXXXNX11110000N* 

V0002 OXXXXXXXXNOHHHHLLLLN* 

The values loaded into the registers are the values desired at the output pins after the preload operation. 

Example 3: Programmer will override any non-X values on input pins in the preload vector. Device is a 16R8 

with active-LOW enable control on pin 11. 


V0001 PXXXXXXXXN011110000N* 

V0002 OXXXXXXXXNOHHHHLLLLN* 

The PLD programmer will override the active LOW enable signal (0) on pin 11 in vector V0001 to perform the 
preload. 
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7.6.2 B Preload Vector 

The "buried register" preload method can be used for devices with internal registers not connected to device pins. 
This may also be used for registers connected to device pins. 

A B preload vector will specify the binary value to be loaded into a register, without regard to the polarity or logic 
of the device (i.e., active HIGH or LOW). If the register is connected to an output pin, then the value 
detected at the output pin will depend on any logic circuitry positioned between the register and the pin. 

A B preload vector has the format: 

Vxxxx BHbbbbbbbbbbbbbbbbbb* <- 20-pin PLD 

The B preload vector numbered Vxxxx (in decimal) will be a vector containing the symbols 0-9 and A-Y. The B 
preload test vector length is equal to the number of pins in the device. The vector is terminated by an asterisk. 

The first vector element from the left will be the B test condition symbol. The second element is an alphanumeric 
character used to identify the register group to preload Register groups will be numbered from 0-9, A-Y. The 
character Z is reserved for future use. 

The remaining test conditions in the vector refer to the states of uo to N-2 registers in the group identified by the 
group number, where N is the number of pins on the device. The allowed test conditions arc "0"," 1", "R", & "N". 

The R test conditions is used by the programmer to read and retain the state of any register. 

For example, if there are 8 registers in a 20-pin PLD, then these 8 registers are assigned to group number 0. Within 
group 0, the 8 registers will be assigned a unique number starting from l. This register number is used to calculate 
the register's position in the preload vector. 

V00Q1 B011110000NNNNNNNNNN* <- 20-pin PLD 

The test vector in the above example is used to preload 8 registers in a 20-pin PLD. Note that these registers can be 
input, output, or internal registers. The next vector elements after the B and group number refer to the states to be 
preloaded into the registers. If there are more vector positions than registers in the PLD, then the rest of the vector 
is filled with the N symbols. 

Example 4: Preloading a device with 12 internal registers. All 12 registers can be defined in one B preload 

vector. 

V0001 B0111000101010NNNNNN* 

Example 5: Preloading the last 6 registers in a 20-pin PLD with 26 internal registers. 

V0001 B1RR010100NNNNNNNNNN* 

Registers 19-26 are contained in register group 1. The status of the 19th and 20th registers is retained by using the 
R test condition. 

Example 6: Preload registers 17 to 23 on a 20-pin device with 26 registers. 

V0001 B0RRRRRRRRRRRRRRRR10* 

V0002 Bill 101 RRRNNNNNNNhJNN* 

Vector V0001 will preload registers 17-18 (in group 0), and V0002 will preload registers 19-23 (group 1). The 
other registers will remain unchanged. 
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The group number for the Xth register and the position of the Xth register within a preload vector can be calculated 
by the following formulas: 

GROUP_NO = (X-l) div (PINS-2) 

POSmONJN_VECTOR = X - ((PINS-2 )*GROUP_NO) + 2 
where: PINS = # of device pins 

div s integer division (fractions are truncated) 

For example, if a 20-pin PLD has 40 registers, then the 31st register will belong m group 1 

GROUP NO = (31-1) div (20-2) 

= 30 div 18 
= 1 

POSITION IN VECTOR = 31 -(18*1) + 2 

= 31-18 + 2 
= 15 


V0001B1RRRRRRRKRRRR1RRRRR* 


group number 1 


register 31 in vector 
position 15 


When a B preload vector is used in a JEDEC file, the QP field must specify all the device pins. The P (pin order 
sequence) will not affect the B preload vector. 

For both the B and P preload vectors. 0 and 1 should be used to specify register pretod values. The 

tested using the L and H symbols. To verify the result of a preload vector (either B or P), use a separate test vector 

or sequence of vectors to test the result of a preload operation. 

Register observation 

Register Observation means viewing the value of a register in a PLD. Output, internal, and mputregist^carLhave 
thehr co ntents examined, as provided for by special access circuitry on a device. For internal registers w particular, 
three types of observation are defined: "product tom", "super-voltage", and "in circuit" observation. 

Product term observation, if provided on the device, is accomplished with dedicated product terms and uses normal 
in-circuit logic levels. The standard input conditions may be used to observe the internal registers in these devices 
if the observability product terms have been so configured by the user. The "super-voltage observation operauon 
uses non standard levels or "super-voltages" to access special modes to observe the internal registers. 

Because algorithms are unique for each device, the following generic methods will allow one set of test vectors to 
work with "second-source" devices. The device programmer/tester will apply the specific algorithm for each 
device type. A T vector will specify the binary value to be tested on a register, without regard to the polarity or 
logic configuration of the device (i.e., active HIGH or LOW). 
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A T vector has the format: 

Vxxxx THbbbbbbbbbbbbbbbbbb* <- 20-pin PLD 
Syntax of T vector 

<group numbei><digit> | # A* | *3* |.. | r V | *Z* 

observation test vector> ::= V <number> <delimiter> 

T <group number> <test conditions> :N-2 

The T vector numbered Vxxxx (in decimal) will be a vector containing the symbols 0-9 and A-Y. The T test vector 
length is equal to the number of pins in the device. The vector is terminated by an asterisk. 

The first vector element from the left will be the T test condition symbol. The second element is an alphanumeric 
character used to identify the register group to observe. Register groups will be numbered from 0-9, A-Y. The 
character Z is reserved for future use. 

The re mainin g test conditions in the vector refer to the states of up to N-2 registers in the group identified by the 
group number, where N is the number of pins on the device. The allowed test conditions are L', If, *X\ & 'NV 

For example, if there are 8 registers in a 20-pin PLD, then these 8 registers are assigned to group number 0. Within 
group 0, the 8 registers will be assigned a unique number starting from 1. This register number is used to calculate 
the register's position in the observation vector. 

V0001 TLHHHHLLLLNNNN^^ <- 20-pin PLD 

The test vector in the above example is used to observe 8 registers in a 20-pin PLD. Note that these registers can 
be input, output, or internal registers. The next vector elements after the T and group number refer to the expected 
states to be tested on the registers. If some registers are not to be tested, an X (or don't care) symbol should be 
used. If there are more vector positions than registers in the PLD, then the rest of the vector is filled with the N 
symbol. 

Example 1: Observing a device with 12 registers. All 12 registers can be tested in one T vector. 

V0001 TOHHHLIiilLHLHLNNNNNN* 

Example 2: Observing the last 6 registers in a 20-pin PLD with 26 registers. 

V0001 T1XXUILHLINNNNNNNNNN* 

The status of the 19th and 20th registers is ignored by using the X test condition. The last 6 registers are contained 
in register group 1. 

Example 3: Test registers 17 to 23 on a 20-pin device with 26 registers. 

V0001 TOXXXXXXXXXXXXXXXXHL* 

V0002 T1HHHLHXXXNNNNNNNNNN* 

Vector V0001 will observe registers 17-18 (in group 0), and V0002 will observe registers 19-23 (group 1). The 
other registers will be ignored. 



JEDEC Standard No. 3-C 
Page 21 

The group number for the Xth register and the portion of the Xth register within an observation vector can be 
calculated by the following formulas: 

GROUP.NO = (X-l) div (PINS-2) 

POSmON_IN_VECTOR = X - ((PINS-2)*GR0UP_N0) + 2 

where: PINS = # of device pins 

div = integer division (fractions are truncated) 

For example, if a 20-pin PLD has 40 registers, then the 31 st register will belong in group l. 

GROUP NO =(31-1) div (20-2) 

= 30 div 18 

POSmONJNVECTOR = 31 -(18*1) + 2 

= 31-18 + 2 
= 15 

V0001 TIXXXXXXXXXXXX1XXXXX* 

A A 

A register 31 in vector 
group number 1 position 15 

When a T vector is used in a JEDEC file, the QP field must specify all the device pins. The P (pin order sequence) 
will not affect the T vector. 

For the T vector, L and H should be used to specify register test values. The registers are preloaded using the 0 and 
1 symbols in a B or P preload vector. 

PROGRAMMER/TESTER OPTIONS 

8.1 Security Fuse (G) 

The security fuse(s) of certain logic devices may be enabled for programming by sending a 1 in the G field. The 
security fuse prevents the reading of the fuse states. 

Syntax for the Security Fuse Field: 

<security fuse> ::= G' <binary-digit> 

Example: 


Gl* 


Enable security fuse programming. 
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8.2 Signature Analysis Test (S, R, T) 


Signature Analysis tests are specified by the S. R. and T fields. The S field defines the starting v«:tor ftrthete* 
Impossible states are 0 and 1. The R field contains the resulting vector or test-sum. The T field denotes the 

number of test cycles to be run. 


Syntax for Signature Analysis Test 

<starting vectoi> *S‘ <test condition>:N 
resulting vectoi> ::= <hex-digit>:8 *** 
<test cycles> T <numbei> **' 

N ::= number of pins on device 


Example: 

S010001000011100011110110* 
R5BCD34A7* 

T01* 


8.3 Access Time (A) 

The A field defines the propagation delay for test vectors m one nanosecond increments. This field may include 
optional subfields. 

Syntax for Access Time 

<access time> *A'{<field characters^ <number> 

Example: 

A25* 

APD25* 


9 EXAMPLES 

9.1 Data File Examples 

<STX> 

LOOOO 

muon n in niiiiiiii mmol liiiiiiiiiiin li mi in n 
n 10 n n n n n n n n n n n noooooocxioooooooooooooooooooo 
oioion ion non n n n n n noooocKxxxiooooooooooooooooooo 
oooooooooooooooooooooooooooooooooooooooooooooooooooooooo 
oioion non ion n n n n n noooooooooooootxiooooooooooooo 
(xxxx)oooo(XKxx)Oooocx)ooooooooooooooo()oooooooooooooooooooo 
oioion ion ion n n n i n n noooooooooooooooooooooooooooo 
oooooqooooooooooooooooooooockjooooooooooooooooooooooooooo* 
<ETX>5718 
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Example 1. Minimum file for device programmer a* defined by Jedec Standard No. 3-A, 


File for PLD 12S8 Created on 8-Feb-85 3:05PM 
6809 memory decode 123-0017-001 
Joe Engineer Advanced Logic Corp * 

QF0448* 

F0* 

U000 1111101111111111111111111111* 

L028 1011111111111111111111111111* 

L056 mommiimimmimii* 

L112 0101011101111011111111111111* 

L224 0101011110111011111111111H1* 

L336 0101011101110111111 111 mill* 

C124E* 

Example 2. Data file for device programming. 


File for PLD 12S8 Created on 8-Feb-85 3:05PM 
6809 memory decode 123-0017-001 
Joe Engineer Advanced Logic Corp * 

QP20* QV8* 

V0001 QOOOOOXXXNXXXHHHLXXN* 

V0002 010000XXXNXXXHHHLXXN* 

V0003 100000XXXNXXXHHHLXXN* 

V0004 110000XXXNXXXHHHLXXN* 

V0005 111OOOXXXNXXXHLHHXXN* 

V0006 111010XXXNXXXHHHHXXN* 

V0007 111100XXXNXXXHHLHXXN* 

V0008 111110XXXNXXXLHHHXXN* 

Example 3. Data File for device testing. 

File for PLD 12S8 Created on 8-Feb-85 3:05PM 
6809 memory decode 123-0017-001 
Joe Engineer Advanced Logic Corp * 

QP20* N Number of pins* 

QF0448• N Number of fuses* 

QV8* N Number of vectors* 

Gl* N Program security fuse* 

FO* N Default fuse state* 

XO* N Default test condition* 

N Fuse RAM Data* 

L0000 

1111101111111111111111111111 

loiimiiiiiiniimniniii 

1110111111111111111111111111 * 

L0U2 

0101011101111011111111111111 * 

L0224 

oioioiiiioiuoiiiinmmn* 

L0336 

01010111011101111111111 Hill* 


October 1983. 
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N Test Vectors* 

V0001 OOOOOOXXXNXXXHHHLXXN* 

V0002 OlOOOOXXXNXXXHHHLXXN* 

V0003 lOOOOOXXXNXXXHHHLXXN* 

V0004 llOOOOXXXNXXXHHHLXXN* 

V0005 lllOOOXXXNXXXHLHHXXN* 

V0006 111010XXXNXXXHHHHXXN* 

V0007 111100XXXNXXXHHLHXXN* 

V0008 111110XXXNXXXLHHHXXN* 

N Fuse RAM checksum* 

C124E* 

N Signature Analysis test information* 

TOl* 

SOOOOOOOOOOOOOOOOOOOO* 

R95E4B822* 

Example 4. Data File for programming and testing with options. 


File for PLD 12S8 Created on 8-Feb-85 3:05PM 
6809 memory decode 123-0017-001 
Joe Engineer Advanced Logic Corp * 

QP20* QF448* QV8* 

FO* 

VI OOOOOOOOONOOOHHHLOON* 

V2 01OOOOOOONOOOHHHLOON* 

V3 1OOOOOOOONOOOHHHLOON * 

V4 11 OOOOOOONOOOHHHLOON* 

LO 1111101111111111111111111111* 

L28 1011111111111111111111111111* 

L56 1110111111111111111111111111* 

L84 OOOOOOOOOOOOOOOOOOOOOOOOOOOO* 

LI 12 0101011101111011111111111111* 

L224 0101011110111011111111111111* 

L336 01010111011101111111111lllll* 

L140 1111111111111111111111111111* 

LI40 OOOOOOOOOOOOOOOOOOOOOOOOOOOO* 

C124E* 

V8 11111111 INI 11HHHL1 IN* 

V6 111010000N000HHHH00N* 

V7 111 1OOOOONOOOHHLHOON* 

V5 111OOOOOONOOOHLHHOON* 

V8 111110000N000LHHH00N • 


Example 5. Data file showing position independence of fields. 



JEDEC Standard No. 3-C 
Page 25 


ANNEX 

A1 INTERACTIVE PROGRAMMING ADDENDUM TO JEDEC STANDARD NO. 3B 

Al.l INTRODUCTION 


Al.1.1 Purpose and Scope 

This addendum was developed to provide limited remote, or microcomputer host, control of PLD programming 
Serf operation is requtred when the final PLD programming pattern cannot be deterrmnM unul 
SKSnS-ie functional inurements of the PLD and, in some cases, the devrce rs programmed and 

functionally tested. 

While in this mode certain mformation files are bidirectionally transferred between a host microcomputer and file 
programming equipment Receipt of JEDEC files are always acknowledged by the ^d 

detectable error device failures are always reported to the microcomputer. The use of perv tag 
vectors are also permitted in continuation files while in the interactive programming mode. 


It is not the intent of this addendum to impose a system configuration that requires a hostnSfiie 
device. All proposed fields axe optional and the manufacturer of programming equipment may elect to provide 
function of the host computer within its programming equipment 


The intent of this addendum is to provide the described functions until superseded by a more comprehensive 
standard supporting computer remote control of programming equipment. 


Al.1.2 Summary of Reporting and Testing Fields 


in various fields. The following list gives the field identifier and 
not defmed in 1.2 of standard 3 A. Detailed descriptions of these 

identifiers are given in section 3 


The reporting and testing information is contained 
description of those required of this addendum but 


Identifier 

Description 

M 

Interactive mode 

ME 

Error message 

MV 

Failed Test Vector 

QE 

Super-voltage definition 


Al.1.3 Changes to Standard No. 3A 

This addendum defines the supporting fields required for an optional mode of operation JJJ® Wjjjj 
equipment This mode of operation is referred to as the interactive programming mode. All files used ni fius mode 
of operation must be contained within <stx> and <etx> characters, end with an xsum (transmission checksum), and 
follow the applicable rules, transmission protocol, and syntax of standard No. 3A except as specifically no 
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A1.2 FILE TYPES 

Al.2.1 General 

The following list contains the three basic file types encountered while in this mode of operation. The A-file is a 
programming equipment to computer transmission file while the other files are computer to programmer 
transmissions. 


tVDC 

originates 

function 

S-file 

computer 

Source 

A-file 

programmer 

Acknowledge 

C-file 

computer 

Continuation 


Al.2.2 Source file (S-file) 

This file type is a programming download file formatted to standard No. 3A. An S-file always includes an Mn* 
field with n=0 identifying the file as a source file indicating a new PLD programming/test session and telling the 
programmer to purge memory of data from any previous PLD program/test session. The MO* field precedes the Ln 
data* fields and the optional test vectors. The programming equipment must always respond to a source file with 
an A-file. The S-file is the initial file if C-files are used and tells the programmer that another file may follow. The 
S-file will be in one of the formats listed below. 


_Sa_Sb 

<stx> <stx> 

MO* MO* 

Ln data* Ln data* 

<etx> Vn vector* 

xsum <etx> 

xsum 


Note: A vector may contain one or more super-voltage defining input characters. Each character is an integer 
between 2 and 9 instead of the most often used 0 or 1. Integers greater than 1 refer to a super-voltage and tells the 
programming equipment to apply a super-voltage of the assigned value (the value of which was previously defined 
by the manufacturers individual device programming specification) to the designated device package pin. This type 
of vector defines which super-voltages are used, and to which device pins the voltages are applied. 

Format Sa is a simple JEDEC formatted file with the additional MO* field telling the programming equipment to 
enter and/or operate in the interactive programming mode. 

Note: Some programming equipment may require manual instruction to enter the interactive programming mode. 
While in this mode all files must adhere to the applicable rules of standard No. 3A and this addendum. 

Format Sb is the same as a Sa-file except for the test vectors. The vectors may contain super-voltage data. 

The following example is a Sb-file where super-voltage M2 has been previously defined in the PLD manufacturers 
programming specification. This file contains standard test vectors and a single Super-Voltage vector (V4). 
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Example: 


<stx?>* MO* QP20* QF392* FO* 

LOOO 

111111111111110111101111 * 

L096 

11111111101101010U10111* 

LI 44 

miinuoionniinmi* 

L192 

moiiinminmiiim 

omoiiimimmimii 

liimiiioiioiommni* 

L288 

liiiiiiiiumoiomiioi* 

QV5* XO* 

VI OOOXXXXXXNXXNNHNNNXN* 

V2 111XXXXXXNXXNNHNNNXN* 

V3 101XXXXXXNXXNNLNNNXN* 

V4 XXX2XXXXXNXXNNNLNNXN* 

V5 XXXOX11XXNXXNHNNNNXN* 

Cl34A* <etx>xsum 

Note: S-files vectors with super-voltage specifying characters can only be used where the super-voltage(s) have been 
pre defined in the PLD manufacturers individual device programming specification. 

After accepting the S-file the programmer will 

a) program the device per the Ln data* field data, 

b) test per any vector fields, 

c) always respond with an A-filc with errors reported, and 

d) be ready to receive a C-file or another S-file 


Al.2.3 Acknowledgement file (A-file) 

This file type is provided by the programmer following receipt of each S-file or C-file and includes either the Ml*. 
MEn*. or MVn vector* fields. The file will be in one of the four formats shown in the following table. 


Aa _Ab_ Ac _Ad 

<stx> <stx> <stx> <StX> 

Ml* MEn* MVn vector* MEn* 

<etx> <etx> <etx> MVn vector* 

xsum xsum xsum <etx> 

xsum 

Format Aa tells the controlling microcomputer that the S-file or C-file was received and processed with no 
detectable errors. 

Format Ab tells the microcomputer of an error occurrence while loading or processing the S-file or C-file. The 
MEn* field signals the errors with n defining the error types. Applicable errors can be defined with as many Mt 
fields as required. The error types are listed in 3.3. 

Format Ac is used if test vectors are included in the downloaded file and vector Mures have occurred. Upon 
receipt of this file the microcomputer will download a correction, or programming, continuation file (Cc-ftle or 
Cd-file), the original or a new S- file for the next PLD, or quit 
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If failures occurred on pin 15 of vectors 2 and 4 in the example Sb-file shown in 2.2, the following Ac-file would be 
sent to the host Note: Vector 4 dictates that a super-voltage be applied to device pin 4. 

Example: 

<St£> 

MV2 111XXXXXXNXXNNLNNNXN* 

MV4 XXX2XXXXXNXXNNHNNNXN* 

<etx> xsum 

Format Ad tells the host that other potentially fatal errors have occurred in addition to test vector failures. The host 
may be able to take corrective action with a C-file if the errors were limited to fuse programming or verification 
failures whose locations may be determined by the failure pattern indicated by the failed vectors. 

Note: The least complex use of the interactive programming mode provides a simple computer controlled device 
programming system. This procedure does not make use of super-voltages, ie., C-files or QE fields and is as 
follows: 

1) Sa-file (Sb if vectors in file) to programmer 

2) Aa, Ab, or Ac-file to microcomputer 

3) microcomputer displays applicable message, ie. 
error, request for new filename, etc. 

4) microcomputer accepts applicable inputs, ie. 
new filename, requests to repeat file, etc. 

5) go to step I if additional devices to be programmed 

6) software exit 

Al.2.4 Continuation file (C-file) 

This file type is software generated, as required for each individual PLD, and is not available or usable for any other 
PLDs. The C-file always includes an Mn* field where n=2 indicating a continuation file and telling the 
programming equipment to hold all relevant PLD data and to permit patching of PLD data as required. 

A continuation file may contain a QEn value*, Ln data*, and/or Vn vector* fields, but need not repeat the QP, QF, 
and F fields of the most recent S-ftle. This file type is always preceded by an S-file and is the only file type permit¬ 
ted to contain QEn value* fields. The file will be in one of the four formats shown in the following table. 

Note: For selected PLDs, on-chip voltage sources can be programmatically altered or defective logic paths can be 
replaced. Ln data* fields, created by the computer and included as part of the C-files, define the new values or 
logic paths. The contents of the Ln data* fields can be algorithmically defined as a result of the user defined logic 
in conjunction with the pattern of vector failures. 


Ca _Cb_Cc_Cd 

<stx> <stx> <stx> <stx> 

M2* M2* M2* M2* 

QEn value* QEn value* Ln data* QEn value* 

Vn vector* <etx> <etx> Ln data* 

<ctx> xsum xsum Vn vector* 

xsum <etx> 

xsum 

Note: Vectors in a C-file may contain super-voltage references. 

Format Ca tells the programming equipment to set the values of one, or more, super-voltages as directed by the QEn 
value* field(s) and to perform the tests per the applicable Vn vector* ficld(s). Values defined in the QE fields 
supersede any predefined super-voltage values. 
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Note' In some cases, on<hip voltage sources can be measured, internal to the the device, by comparing their vatas 
to external voltage references (the super-voltages) applied to the device pins during certain vector tests. The QEn 
value*fields define the value of the external voltage references. The vectors define which super-voltages are used, 
and to which device pin the voltages are provided. The result of the on-chip voltage comparison is seen as logr 
level device outputs and referenced in the vectors as H or L output level identifying characters. 


Devices may fail one or more test vectors because predefined internal voltage references do not agree with internal 
references developed as a result of device programming. 


Format Cb permits changing the values of the super-voltage and performing tests with predefined vectors (those 
contained in a source file or earlier continuation file). 

Format Cc is used to change the value of on-chip voltage sources by programming selected cells. This ts the 
reaurred format when the default values of the super-voltages are defined in the programming specification, tested 
with a Sb-file, and one-pass correction is acceptable. This file type is also used when the super-voltages have been 
previously defined in an earlier C-file within the current programming/testing session (while programming or 
testing the same PLD). 

Following is an example Cc-file transmitted in response to the Ac-file shown in 2.3. The vectors that need be 
retested after the cells are programmed need not be repeated in this file. All vectors md other applicable PLD 
previously transmitted are resident in the programmer until a new S-file is provided. Cell numbers 384 through 3 
in this file are reserved to alter internal voltage references. The source Sb-file for this example is shown in 2.2. 
Note that the C (fuse checksum) has been updated to reflect the changes in the fuse map. 

Example: 

<stx> M2* 

L384 

11010010 * 

C13AB* <etx>xsum 

Format Cd changes the values of on-chip and super-voltage sources and defines one or more appropriate vectors to 
test the results. 

Note: The least complex use of the QE fields in the interactive programming mode is as follows: 

1) Sc-file (Sd if non-super-voltage defining vectors are required) to programmer 

2) A-file to microcomputer 

3) if no vector fails then go to step 6 

4) Cc-file to programmer 

5) A-file to microcomputer 

6) message and/or operator inputs at microcomputer 

7) go to step 1 if additional devices to be programmed 

8) software exit 

This provides a simple computer controlled device programming system with a one-pass correction of on-chip 
voltage sources. 
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A1.3 FILE REPORTING FIELDS 
Al.3.1 General 

Two major field identifiers arc used in the implementation of this addendum. The Q field identifier is defined in 
standard No. 3A. The M field identifier is new to this addendum. 

<field identified ::= TvT | *0* 


Field Identifiers 

M - mode Q - value (per standard 3A) 

Al.3.2 Mode declaration field (Mn) 

The Mn* field in host provided JEDEC files instructs the programming equipment to enter and/or continue 
operation in the interactive (LOAD, GO, and REPORT ERROR) programming mode. The MO field is contained in 
all S-files, Ml in A-files where no errors are being reported, and M2 in all C-flles. 

Al.3.3 Error reporting (MEn) 

This field is found only in A-files reporting errors detected by the programming equipment More than one MEn 
field may be in the file if more than one error type is detected with n indicating the error type. 

The MEn* field is required if a fatal, or potentially fatal, error or failure occurs. The host microcomputer provides 
the user with the appropriate message and takes the appropriate action if applicable when the cause of an error is 
identified. The response to PLD programming failures is based in some cases on user inputs. The final action 
taken may be to end the session, initiate corrective action with a C-file, or to begin a new PLD programming session 
with an S-file. 

While in this mode of operation the programming equipment will continue processing the file after certain error 
types occur as defined by the PLD manufacturers programming specification. If a programming, verification, or 
vector failure were to occur, the equipment would continue the programming, verification, vector testing, and report 
all detected error types to the host microcomputer. The final determination to abort the program/verification/test 
session is made by the microcomputer or by error limits as defined in the PLD programming specification. 

Error message field (MEn) 


<error message> ME’ <number> '*’ 
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Error messages: 

field error type 

MEO* undefined error 

ME1* no device in socket 

ME2* device insertion error 

ME3* reversed device 

ME4* device over-current fault 

ME5* faulty device 

ME6* electronic ID verify error 

ME7* load or file error 

ME8* secured device 

ME9* security fuse programming error 

ME 10* fuse checksum 

ME11 ‘transmission checksum 

ME 12‘programming failure 

ME13‘verify failure 

ME 14‘cell pre-programmed to wrong state 
ME 15‘preload not supported by device 
ME 16‘test vector syntax error 
ME 17 * super-voltage definition error 
ME 18‘unrecoverable error 

Note: If a particular error type is not defined the MEO* field may be used. Certain error types such as ME12, 
ME13, and ME14 need not necessarily be interpreted as fatal by the host microcomputer. The device programming 
specification may specify limits for certain error types and expect an ME18* field if the number of programming 
failures, normally reported by an ME12‘ field, exceeded the limit 

Al.3.4 Vector failure field (MVn) 

This field is found only in A-files reporting test vector failures to the host. All vector failures are reported in the 
same sequence as listed in the source file. 

One MVn vector* field exists for each failed vector with n indicating the vector number. An MVn vector* field 
indicates a failed vector. The vector number (n) and input data are the same as that most recently provided by the 
computer in the S-file or C-file. The vector data reflects the data as seen by the programming equipment allowing 
the computer to compare the failed vectors with the original vectors to locate the errors and take the appropriate 
action. 

A1.4 DEVICE TESTING FIELDS 
Al.4.1 General 

The use of QE* fields and associated vectors (with super-voltage data) permit the measurement of on-chip voltage 
references. The actual value of the voltages may be determined, in part, by the user defined logic, or digital data, 
programmed into the device. A separate QE field is required for each super-voltage to be defined in the vectors, 
and all must occur in the file prior to the associated test vectors. 
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Al.4.2 Super-Voltage Definition (QEn) 

The use of the QE field may provide information regarding device characteristics. Many new devices allow for, and 
require that, these device characteristics be altered if they are not satisfactory. This procedure will require that 
additional JEDEC files be acted upon by the programmer depending on the results of, and in a manner dictated by, 
the*previous file. This procedure can only be accomplished in a C-file after the recognition of a MO* field in the 
original JEDEC formatted file (S-file). Under no circumstances may a source file contain a QE field. 


Syntax of QE field: 

<super-voltage> ::= 'QE' <digit> <delumtex> <number> '*' 

Example: 

QE3 10500* Indicates Super-Voltage #3 is 10.5 volts 
QE5 64300* Indicates Super-Voltage #5 is -14.3 volts 

Definition 

Each QEn d* field, in conjunction with proper Vn vector* fields, specifies the value of a super-voltage used within 
one, or more, of those vectors. 

n is an integer 2 to 9 representing one of the eight super-voltages which may be defined, 

d is a decimal number from 0 to 99999 (1-5 digits) defining the value, in millivolts, of the super-voltage. The 

actual voltage is d mod 50000, permitting values from -49.999 volts to +49.999 volts to be defined. The 
numbers from 0 to 49999 define the positive voltages. 

A1.5 IMPLEMENTATION CONSIDERATIONS 

Al.5.1 Standard No. 3A 

Standard No. 3A describes a means of patching the fuse list portions of files in programmer memory. To ensure 
that new files completely replace earlier files in the interactive programming mode the programmer must recognize 
the M0* as being in a new (source) file and as a signal to clear memory. 

All source files must adhere strictly to the standard. Continuation (C-files) need not repeat previously transmitted 
PLD data to the programmer. 
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Al.5.2 Programming Specifications 

The use of a QE field requires that the device manufacturers programming specification include the number of 
super-voltages and the following data, if applicable, for each: 

a) identification number (2 through 9) 

b) default value (lower limit if not defined) 

c) upper and lower limit 

d) slew rate limits of each edge 

e) minimum hold time to vector execution 

f) device pin to which it is applied 

g) the source/sink current required 

h) the cell numbers affecting QE values 


Comment The following limitations may restrict the use QE fields for some programming equipment 


1) number of programmable voltage sources 

2) device pins to which the voltages may be applied 

3) the accuracy and resolution of the voltage sources 

Note: the source/sink current requirements of the target pin for a super-voltage may have a dramatic effect on the 
accuracy and resolution of the super-voltage. 

Al.5.3 Programming Equipment QE field support requirements 


For device programmers supporting this field, the recognition or acceptance of a QE field, or a vector using a 
super-voltage, would be restricted to supported devices and the use detailed in the applicable device manufacturer's 
programming specification. The device programmer must check QE values and compare to specified limits. 

The device programmer should ensure that file type is appropriate for the device/pinout code and check 
super-voltage specifying vector locations and compare to the specified pins. 

A1.6 EXAMPLE FILES 

Al.6.1 Voltage reference adjustment 

These examples represent a single PLD programming session where the values of a number of on-chip voltage 
sources are changed. 

<stx>* MO* QP20* QF2056* FO* 

L0000 

liiiiiiiiiiiiniiiiiiiiniiiiin 

10111111110111111111101010011101 

L1024 

10111111110111111111111111101111 

11111111110111111111101111101111 * 

L1792 

llllllllllllllllllllllllllllllll 
10111111111111111111111011111110 * 

QV5* X0* 

VI 000XXXXXXNXXNNHNNNXN* 

V2 100XXXXXXNXXNNLNNNXN* 

V3 111XXXXXXNXXNNHNNNXN* 

V4 101XXXXXXNXXNNLNNNXN* 

Ccsum* <etx>xsum 
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Example 1. An Sb-file with vectors not dictating a super-voltage where an internal voltage reference will be 
affected, in part, by the logic pattern defined by the L fields. Programmer memory is reserved for subsequent L and 
V fields. Previous PLD data is erased from memory. 

<stx>Ml * <etx>xsum 

Example 2. An Aa-file from the programmer indicating no errors in previously transmitted Sb-file. 

<stx>M2* QE2 10100* QE3 10300* QE4 10500* 

V5 234XXXXXXNXXLLLLLLXN* 

<et£>xsum 

Example 3 A Ca-file with super-voltage assignments, based on the Sb-file previously transmitted- Any default 
super-voltage values that may have been specified by the PLD manufacturers device programming specification are 
replaced by the values specified in this file. The previously transmitted QV and X fields are held valid. The vector 
is patched into the programmer memory. 

<stx> 

MV5 234XXXXXXNXXLHLLHHXN* 

<etx>xsum 

Example 4. An Ac-file providing the data for a vector failure in the Sb-file. 

<stx> M2* 

L2048 

00101110 * 

Ccsum* <etx>xsum 

Example 5. The Cc-file alters the values of on-chip voltage references by programming additional fuses. The new 
values were determined by the pattern of vector failures. The pattern of vector failures was determined by the logic 
pattern programmed into the device and the original values of the on-chip references. The fuse checksum reflects 
the new fuse map. All resident vectors are tested after programming. The values of the super-voltages are 
unchanged. 

<stx>Ml* <etx>xsum 

Example 6. The final Aa-file for the session indicating a correct programming of the on-chip voltage sources. A 
new PLD session is initiated by an S-file. 
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Al.6.2 Logic replacement 

This example represents a PLD programming session where redundant logic paths are programmed to replace 
existing, defective, paths. 


<stx>* MO* QP20* QF2056* FO* 

L0000 

10111111110101010110101010011101 
LI 024 

10111101101110101011111111101111 

11111111110111111111101111101111 * 

LI 792 

11111111101111110111101111010111 

10111111111111111111111011111110 * 

QV4* XO* 

VI 000XX1OXXNXXNNHLHNXN* 

V2 100XX11XXNXXNNLLLNXN • 

V3 111XX11XXFDOCNNHHLNXN* 

V4 10IXX10XXNXXNNLLHNXN* 

Ccsum* <etx>xsum 

Example 1. An Sb-file with vectors (no super-voltage data). Since this is a source file, previous PLD data is erased 
from memory. 

<stx> 

MV1 OOOXXlOXXTOCXhnsIHIXNXN 
MV3 111XX11XXNXXNNHHHNXN* 

<etx>xsum 

Example 2. An Ac-file providing vector failure data (pin 18). 

<stx> M2* 

L2048 

10101110 * 

Ccsum* <etx>xsum 

Example 3. The Cc-file replaces the failed logic path by programming selected additional fuses. The replacement 
path was determined by the pattern of vector failures and the logic pattern programmed into the device by the source 
file. The fuse checksum reflects the new fuse map. Resident vectors arc tested after programming. Had the logic 
re-routing cells been previously programmed a fuse checksum failure would have been given. 

<stx>Ml* <etx>xsum 


Example 4. The final Aa-file for the session indicates correct programming and operation of the logic path 
replacement circuits. 



